In the field of computer security, the term “honeypot” is used to refer to a trap set to detect, deflect, or counteract attempts at an unauthorized use or malicious use of information systems. Generally, a honeypot is a decoy server or end station that appears to contain information or a resource of value to attackers, but in actuality may be isolated and/or monitored and not include legitimate information or resources. Honeypots allow system operators to learn how attackers probe and attempt to gain access to end stations by maintaining a record of the attacker's activities. Further, honeypots may also gather evidence to be used to assist in the apprehension or prosecution of attackers.
Thus, honeypots are security resources that are intended to be probed, attacked, and compromised to allow for information about the attacker and the techniques of the attacker to be discovered. Production honeypots, as compared to research honeypots that seek to research threats being used, are typically placed within a production network (i.e., a network actively used for other purposes unrelated to threat/attack detection alone) along with other production computing resources used by authorized users of the production network to improve the security of the production network.
Honeypots can be classified as either high-interaction or low-interaction. High-interaction honeypots may utilize actual computing resources and/or software (e.g., a fully-installed and configured Unix system) to interact with potential attackers to provide a detailed and complete view of an attack, whereas low-interaction honeypots typically emulate one or more potentially vulnerable services or software (e.g., a standalone FTP server, or a standard Unix server with several typically attacked services, such as Finger, Telnet, and/or File Transfer Protocol (FTP)), and thus cannot typically become infected or compromised by an attack.
Some security approaches have turned to the use of “honey tokens” to attempt to detect intrusions. The term “honey token” refers to honeypots that are not servers or server end stations. Instead, honey tokens can be pieces of information placed in server data repositories that are easy to detect when used/accessed, and are rarely (if ever) used/accessed by an authorized user. For example, a honey token could be a user account configured for a server or server end station that is not assigned to or used by any authorized user, or a database entry that would typically only be selected by a malicious query. Accordingly, a compromise of the server having placed thereon a honey token can be identified when, for example, the honey token is detected outside of the server's data repository, or when an access to the honey token within the server data repository occurs. Thus, upon an attempted use of the user account honey token (e.g., an attempt to log on to a server) or an attempted access of the database entry including a honey token, an alarm can be issued to notify interested parties about the occurrence of the compromise.
However, successfully deploying and utilizing honeypots and honey tokens in enterprises has proven extremely challenging. For example, to implement honeypots, additional computing resources (e.g., server end stations, special-purpose software, etc.) need to be acquired, configured, deployed, managed, monitored, etc., by the implementing enterprises. In many cases, these enterprises often lose the desire or ability to maintain the operation of these systems over time.